Traditional security protocols (e.g., Secure Sockets Layer (SSL), Transport Layer Security (TLS), Internet Key Exchange (IKE), etc.) negotiate session keys that are authenticated using digital certificates, keys, or shared secrets (e.g., a pass phrase). The session keys are used to encrypt and decrypt subsequent communications carried across a secured channel.
FIGS. 1A-B illustrate an example prior-art authentication sequence (i.e., an authentication protocol encapsulation block (PEB)) executed between two endpoints A and B to negotiate (i.e., derive) session keys. Endpoints A and B are one of a variety of computing devices or platforms (e.g., a computer, a server, a personal digital assistant (PDA), a cellular phone, an Internet kiosk, etc.) connected together, for example, by a computer network, a bus, a wireless communication link, a serial channel, etc. The endpoints A and B may communicate in a master-slave, a client-server, or a peer-to-peer configuration.
The example authentication PEB of FIGS. 1A-B begins with endpoints A and B exchanging authentication attributes (i.e., identifying information) (block 102 of FIG. 1A). The exchanged attributes (e.g., public keys, digital signatures, certificates, attestation information, etc.) allow an endpoint to authenticate information received from the other endpoint. For example, endpoint A encrypts (or digitally signs) an attribute (e.g., attestation information) using a private key (that is only known to endpoint A) and sends the encrypted attribute and a public key (that corresponds to the private key which remains known only to endpoint A) to endpoint B.
Next, using received authentication attributes (e.g., public keys), the endpoints A and B authenticate the received attributes (block 104). For example, endpoint B uses the public key (received from endpoint A) to decrypt the received encrypted attribute (e.g., attestation information). If the decryption is successful, endpoint B knows that the received attribute is authentic (i.e., sent by endpoint A).
In the example authentication PEB of FIG. 1A, endpoint A then generates a high entropy random number (i.e., nonceA), digitally signs nonceA (using a private key of endpoint A), encrypts the signed nonceA (using a public key of endpoint B), and sends the encrypted and signed nonce to endpoint B (block 106). Endpoint B then decrypts and authenticates (using a private key of endpoint B, and a public key of endpoint A) the received nonceA (block 108). Endpoint B then generates a second high entropy random number (i.e., nonceB), creates a cryptographic combination (e.g., arithmetic addition, exclusive-or, hash, etc.) of nonceA and nonceB, signs and encrypts the nonce combination, and sends the encrypted and signed nonce combination to endpoint A (block 110). Endpoint A authenticates the received nonce combination (block 112) and sends an encrypted and signed version of nonceB back to endpoint B (block 114).
The example authentication PEB continues with block 120 of FIG. 1B. The endpoints A and B determine a master secret from nonceA and nonceB. For example, the master secret may be determined using a cryptographic combination of nonceA, nonceB, and a cryptographic hash of the handshake messages (i.e., exchanged identifying information or authentication attributes) (block 120). Using one of a variety of techniques (e.g., “Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)”, Internet Engineering Task Force (IETF) Request for Comment (RFC) 3079, March 2001), session keys are derived from the master secret (block 122). By exchanging and basing session keys on nonceA and nonceB, the authentication PEB of FIGS. 1A-B reduces the risk of replay attacks, man-in-the-middle attacks, etc.
Using techniques similar to those discussed above, the endpoints A and B exchange some initial data (block 124). Each endpoint A and B then determines if the received data is valid (e.g., decrypted correctly) (block 126). If the received data is valid (block 126), the session is authenticated and secure communications can proceed using the established session (block 128). Otherwise, the session is not authenticated, and, thus, secure communication can not properly proceed using the new session (block 130).